SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Programmation fonctionnelle</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Programmation fonctionnelle</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="fr" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="fr" dir="ltr">La programmation fonctionnelle est un <a href="Paradigme_(programmation)" title="Paradigme (programmation)">paradigme de programmation</a> de type <a href="Programmation_d%C3%A9clarative" title="Programmation déclarative">déclaratif</a> qui considère le calcul en tant qu'évaluation de <a href="Fonction_(math%C3%A9matiques)" title="Fonction (mathématiques)">fonctions mathématiques</a>.

Comme le <a href="Changement_d'%C3%A9tat" title="Changement d'état">changement d'état</a> et la mutation des données ne peuvent pas être représentés par des évaluations de fonctions sans <a href="Effet_de_bord_(informatique)" title="Effet de bord (informatique)">effet de bord</a><a href="#cite_note-monades-1">[1]</a>, la programmation fonctionnelle les écarte : au contraire, elle met en avant l'application des fonctions, contrairement au modèle de <a href="Programmation_imp%C3%A9rative" title="Programmation impérative">programmation impérative</a>, lequel met en avant les changements d'état<a href="#cite_note-2">[2]</a>.

Un langage fonctionnel est donc un <a href="Langage_de_programmation" title="Langage de programmation">langage de programmation</a> dont la syntaxe et les caractéristiques encouragent la programmation fonctionnelle. Alors que l'origine de la programmation fonctionnelle peut être trouvée dans le <a href="Lambda-calcul" title="Lambda-calcul">lambda-calcul</a>, le langage fonctionnel le plus ancien est <a href="Lisp" title="Lisp">Lisp</a>, créé en <a href="1958" title="1958">1958</a> par <a href="John_McCarthy" title="John McCarthy">McCarthy</a>. Lisp a donné naissance à des variantes telles que <a href="Scheme" title="Scheme">Scheme</a> (<a href="1975" title="1975">1975</a>) et <a href="Common_Lisp" title="Common Lisp">Common Lisp</a> (<a href="1984" title="1984">1984</a>)<a href="#cite_note-3">[3]</a> qui, comme Lisp, ne sont pas ou peu <a href="Type_(informatique)" title="Type (informatique)">typées</a>. Des langages fonctionnels plus récents tels <a href="ML_(langage)" title="ML (langage)">ML</a> (<a href="1973" title="1973">1973</a>), <a href="Haskell" title="Haskell">Haskell</a> (<a href="1987" title="1987">1987</a>), <a href="OCaml" title="OCaml">OCaml</a>, <a href="Erlang_(langage)" title="Erlang (langage)">Erlang</a>, <a href="Wolfram_Language" title="Wolfram Language">Wolfram Language</a> (<a href="1988" title="1988">1988</a>)<a href="#cite_note-4">[4]</a>,<a href="#cite_note-5">[5]</a>, Clean et <a href="Oz_(langage)" title="Oz (langage)">Oz</a>, <a href="CDuce" title="CDuce">CDuce</a>, <a href="Scala_(langage)" title="Scala (langage)">Scala</a> (<a href="2003" title="2003">2003</a>), <a href="F_Sharp" title="F Sharp">F#</a> ou <a href="PureScript" title="PureScript">PureScript</a> (<a href="2013" title="2013">2013</a>), Agda <a href="https://en.wikipedia.org/wiki/Agda_(programming_language)" class="extiw external" title="en:Agda (programming language)">(en)</a> sont fortement typés.

<div class="mw-heading mw-heading2"><h2 id="Machine_à_états_et_effets_secondaires">Machine à états et effets secondaires</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Programmation_fonctionnelle">Programmation fonctionnelle</h3></div>

La programmation fonctionnelle s'affranchit des effets secondaires (ou <a href="Effet_de_bord_(informatique)" title="Effet de bord (informatique)">effets de bord</a>) en interdisant toute opération d'<a href="Affectation_(informatique)" title="Affectation (informatique)">affectation</a><a href="#cite_note-monades-1">[1]</a>.

Le paradigme fonctionnel n'utilise pas de <a href="Automate_fini" title="Automate fini">machine à états</a> pour décrire un programme, mais un emboîtement de fonctions qui agissent comme des « boîtes noires » que l'on peut imbriquer les unes dans les autres. Chaque boîte possédant plusieurs <a href="Param%C3%A8tre_(programmation_informatique)" title="Paramètre (programmation informatique)">paramètres</a> en entrée mais une seule sortie, elle ne peut sortir qu'une seule valeur possible pour chaque <a href="Uplet" title="Uplet">n-uplet</a> de valeurs présentées en entrée.

Ainsi, les fonctions n'introduisent pas d'effets de bord. Un programme est donc une <a href="Application_(math%C3%A9matiques)" title="Application (mathématiques)">application</a>, au sens mathématique, qui ne donne qu'un seul résultat pour chaque ensemble de valeurs en entrée. Cette façon de penser, très différente de la démarche de la programmation impérative, est l'une des causes principales de la difficulté qu'ont les programmeurs formés aux langages impératifs pour aborder la programmation fonctionnelle.

Cependant, elle ne pose généralement pas de difficultés particulières aux débutants qui n'ont jamais été exposés à des langages impératifs<a href="#cite_note-6">[6]</a>.

Un avantage important des fonctions sans effet de bord est la facilité que l'on a à les tester unitairement. Par ailleurs, l'usage généralisé d'une gestion de mémoire automatique par l'intermédiaire d'un <a href="Ramasse-miettes_(informatique)" title="Ramasse-miettes (informatique)">ramasse-miettes</a> simplifie la tâche du programmeur.

En pratique, pour des raisons d'efficacité, et du fait que certains algorithmes s'expriment aisément avec une machine à états, certains langages fonctionnels autorisent la <a href="Programmation_imp%C3%A9rative" title="Programmation impérative">programmation impérative</a> en permettant de spécifier que certaines variables sont assignables (ou mutables selon la dénomination habituelle), et donc la possibilité d'introduire localement des effets de bord[réf. nécessaire]. Ces langages sont regroupés sous le nom de langages fonctionnels impurs.

Les langages dits purement fonctionnels n'autorisent pas la programmation impérative<a href="#cite_note-monades-1">[1]</a>. De fait, ils sont dénués d'effets de bord et protégés contre les problèmes que pose l'<a href="Programmation_concurrente" title="Programmation concurrente">exécution concurrente</a>. On peut voir par exemple ce qui a été fait dans le cadre du langage <a href="Erlang_(langage)" title="Erlang (langage)">Erlang</a>.

La mise en œuvre des langages fonctionnels fait un usage sophistiqué de la <a href="Pile_(informatique)" title="Pile (informatique)">pile</a> car, afin de s'affranchir de la nécessité de stocker des données temporaires dans des tableaux, ils font largement appel à la <a href="Algorithme_r%C3%A9cursif" title="Algorithme récursif">récursivité</a> (fait d'inclure l'appel d'une fonction dans sa propre définition). L'une des multiples techniques pour rendre la compilation de la récursivité plus efficace est une technique dénommée <a href="R%C3%A9cursion_terminale" title="Récursion terminale">récursion terminale</a> (en <a href="Anglais" title="Anglais">anglais</a> : tail-recursion), qui consiste à accumuler les résultats intermédiaires dans une case mémoire de la pile et à la passer en paramètre dans l'appel récursif. Ceci permet d'éviter d'empiler les appels récursifs dans la pile en les remplaçant par une simple succession de sauts. Le code généré par le compilateur est alors similaire à celui généré par une boucle en impératif. Certains langages comme <a href="Scheme" title="Scheme">Scheme</a>, <a href="Scala_(langage)" title="Scala (langage)">Scala</a>, <a href="OCaml" title="OCaml">OCaml</a> et Anubis optimisent automatiquement les appels récursifs de cette manière.

<div class="mw-heading mw-heading3"><h3 id="Programmation_impérative_et_effets_de_bord">Programmation impérative et effets de bord</h3></div>

La programmation impérative s'appuie sur le modèle des <a href="Automate_fini" title="Automate fini">machines à états</a> (voir aussi <a href="Machine_de_Turing" title="Machine de Turing">machine de Turing</a> et <a href="Architecture_de_von_Neumann" title="Architecture de von Neumann">Architecture de von Neumann</a>), avec une <a href="M%C3%A9moire_(informatique)" title="Mémoire (informatique)">mémoire centrale</a> et des <a href="Instruction_informatique" title="Instruction informatique">instructions</a> qui modifient son état grâce à des affectations successives. Un tel programme est représenté par une machine à états (voir <a href="Machine_%C3%A0_compteurs" title="Machine à compteurs">machine à compteurs</a>) qui représente les états successifs de la mémoire. Cela nécessite pour le programmeur d'avoir à tout instant un modèle exact de l'état de la mémoire que le programme modifie.

Afin de réduire la <a href="Th%C3%A9orie_de_la_complexit%C3%A9_(informatique_th%C3%A9orique)" title="Théorie de la complexité (informatique théorique)">complexité</a> de cette tâche, de nombreuses techniques réduisent le nombre de variables à gérer à un même instant, la plupart relèvent de la <a href="Programmation_structur%C3%A9e" title="Programmation structurée">programmation structurée</a> et de l'<a href="Encapsulation_(programmation)" title="Encapsulation (programmation)">encapsulation de données</a> :

<ul><li>les variables dites automatiques ou <a href="Variable_locale" title="Variable locale">locales</a>, sont restreintes au seul domaine (procédure, méthode, etc.) dans lequel elles sont utiles. Leur <a href="Port%C3%A9e_lexicale" title="Portée lexicale">portée</a> est alors strictement limitée à ce domaine.</li>

<li>l'<a href="Encapsulation_(programmation)" title="Encapsulation (programmation)">encapsulation de données</a>, notamment celle de la <a href="Programmation_orient%C3%A9e_objet" title="Programmation orientée objet">programmation orientée objet</a>, restreint la manipulation des variables au seul domaine de la <a href="Classe_(informatique)" title="Classe (informatique)">classe</a> à l'intérieur de laquelle elles sont définies (utilisation d'<a href="Attribut_(informatique)" title="Attribut (informatique)">attributs</a> privés)</li></ul>

Ces variables ont alors vocation à être désallouées par le <a href="Compilateur" title="Compilateur">compilateur</a> ou <a href="Interpr%C3%A8te_(informatique)" title="Interprète (informatique)">interpréteur</a>, immédiatement en sortie de procédure ou via un <a href="Ramasse-miettes_(informatique)" title="Ramasse-miettes (informatique)">ramasse-miettes</a>.

Cependant, il arrive que la <a href="Conception_de_logiciel" title="Conception de logiciel">conception</a> choisie par le programmeur l'amène à modifier dans certaines procédures, volontairement ou non, des variables ou des zones de mémoire « partagées », ne relevant pas structurellement de la procédure.

Il se trouve qu'en programmation impérative, ces modifications «périphériques», désignées sous le terme générique d'<a href="Effet_de_bord_(informatique)" title="Effet de bord (informatique)">effets secondaires</a> (ou <a href="Effet_de_bord_(informatique)" title="Effet de bord (informatique)">effets de bord</a>), sont de facto plus la règle que l'exception[réf. nécessaire] et compliquent grandement la compréhension des programmes. Par conséquent, ils sont la source de nombreuses difficultés et de <a href="Bug_(informatique)" title="Bug (informatique)">bugs</a> : en effet, si on oublie de mettre à jour certaines données partagées ou qu'au contraire on les modifie sans en mesurer tous les effets de bord, si l'ordre chronologique des affectations par les différents composants du logiciel est inadéquat, ou si une zone de mémoire est désallouée au mauvais moment, le programme se retrouve dans un état imprévu, incohérent voire instable et le programmeur est souvent incapable de détecter l'origine de l'erreur et s'il y réussit c'est au prix d'une <a href="Instrumentation_du_code_source" title="Instrumentation du code source">instrumentation lourde des programmes</a>.

<div class="mw-heading mw-heading2"><h2 id="Transparence_référentielle">Transparence référentielle</h2></div>

Les langages fonctionnels ont comme autre propriété la <a href="Transparence_r%C3%A9f%C3%A9rentielle" title="Transparence référentielle">transparence référentielle</a>. Ce terme recouvre le principe simple selon lequel le résultat du programme ne change pas si on remplace une expression par une expression de valeur égale. Ce principe est violé dans le cas de procédures à effets de bord puisqu'une telle procédure, ne dépendant pas uniquement de ses arguments d'entrée, ne se comporte pas forcément de façon identique à deux instants donnés du programme.

Prenons un exemple. En <a href="C_(langage)" title="C (langage)">C</a>, si n désigne une <a href="Variable_globale" title="Variable globale">variable globale</a> contenant un entier à incrémenter (donc une case mémoire visible par tout le programme), et si inc(k) est une fonction qui augmente la valeur de n de la quantité k :

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>int n = 2;

int inc(int k) { /* incrémentation par effet de bord */

n = n + k;

return n;

}

f(inc(1) + inc(1));

</pre></div>

Dans cet exemple, la fonction inc(i) ne renvoie pas la même valeur lors des deux appels : l'un des arguments de la fonction f vaudra 2 + 1 = 3 et l'autre 3 + 1 = 4. Il s'avère donc impossible de remplacer inc(i) + inc(i) par 2 * inc(i) car la valeur de inc(i) diffère à chaque appel. Ce comportement est fondamentalement différent de celui d'une fonction mathématique. À l'échelle d'un programme important, cela signifie que le remplacement d'une fonction par une autre peut nécessiter des modifications à d'autres endroits du programme, et qu'il peut s'avérer nécessaire de retester l'intégralité du système, car on n'est pas assuré qu'un tel remplacement n'a pas modifié son comportement global. Au fur et à mesure que la complexité du système augmente, le coût d'un changement s'accroît aussi.

À l'inverse, la propriété de transparence référentielle permet d'assurer que le remplacement d'une fonction par une autre équivalente ne risque pas de modifier le comportement global du programme. Autrement dit, elles sont mathématiquement égales. Cette propriété facilite la maintenance logicielle. Elle permet aussi d'appliquer de façon automatique des preuves de fonctionnement. Elle a enfin pour autre avantage de sensiblement réduire l'importance de l'ordre d'exécution, celui-ci étant assuré par l'ordre d'appel des fonctions ; un corollaire est que la <a href="Parall%C3%A9lisme_(informatique)" title="Parallélisme (informatique)">parallélisation</a> d'un programme fonctionnel peut être réalisée de façon automatique et que les optimisations que peuvent effectuer les compilateurs sont plus faciles à mettre en œuvre.

<div class="mw-heading mw-heading2"><h2 id="Des_fonctions_passées_en_paramètre">Des fonctions passées en paramètre</h2></div>

Les langages fonctionnels emploient des <a href="Types_de_donn%C3%A9es" class="mw-redirect" title="Types de données">types</a> et des <a href="Structure_de_donn%C3%A9es" title="Structure de données">structures de données</a> de haut niveau comme les listes extensibles. Il est ainsi généralement possible de réaliser facilement des opérations comme la <a href="Concat%C3%A9nation" title="Concaténation">concaténation</a> de listes, ou l'application d'une fonction à une liste — le parcours de la liste se faisant de façon récursive —, en une seule <a href="Ligne_de_code" title="Ligne de code">ligne de code</a>.

Un mécanisme puissant des langages fonctionnels est l'usage des <a href="Fonction_d'ordre_sup%C3%A9rieur" title="Fonction d'ordre supérieur">fonctions d'ordre supérieur</a>. Une fonction est dite d'ordre supérieur lorsqu'elle peut prendre des fonctions comme arguments (aussi appelées <a href="Fonction_de_rappel" title="Fonction de rappel">callback</a>) ou renvoyer une fonction comme résultat. On dit aussi que les fonctions sont des objets de première classe, ce qui signifie qu'elles sont manipulables aussi simplement que les types de base. Les programmes ou fonctions qui manipulent des fonctions correspondent, en mathématiques, aux <a href="Fonctionnelle" title="Fonctionnelle">fonctionnelles</a>. Les opérations de dérivation et d'intégration en sont deux exemples simples. Les fonctions d'ordre supérieur ont été étudiées par <a href="Alonzo_Church" title="Alonzo Church">Alonzo Church</a> et <a href="Stephen_Cole_Kleene" title="Stephen Cole Kleene">Stephen Kleene</a> dans les <a href="Ann%C3%A9es_1930" title="Années 1930">années 1930</a>, à partir du formalisme du <a href="Lambda-calcul" title="Lambda-calcul">lambda-calcul</a>, qui a influencé la conception de plusieurs langages fonctionnels, notamment celle d'<a href="Haskell" title="Haskell">Haskell</a>. La <a href="Th%C3%A9orie_des_cat%C3%A9gories" title="Théorie des catégories">théorie des catégories</a> cartésiennes fermées constitue une autre approche pour caractériser les fonctions, à l'aide de la notion de <a href="Probl%C3%A8me_universel" class="mw-redirect" title="Problème universel">problème universel</a>. Le langage Anubis s'appuie sur cette théorie.

<div class="mw-heading mw-heading2"><h2 id="Impact_du_paradigme_fonctionnel">Impact du paradigme fonctionnel</h2></div>

Au début des années 2000, la programmation fonctionnelle a commencé à sortir du milieu académique. Dans le milieu industriel, les langages <a href="Erlang_(langage)" title="Erlang (langage)">Erlang</a> (développé par <a href="Ericsson" title="Ericsson">Ericsson</a> pour des besoins de programmation concurrentielle et des impératifs de robustesse), <a href="Common_Lisp" title="Common Lisp">Common Lisp</a>, <a href="OCaml#Industrie" title="OCaml">OCaml</a> et <a href="Scheme" title="Scheme">Scheme</a> sont utilisés. Mais le développement des langages fonctionnels est limité par le déficit en outils et en bibliothèques de qualité commerciale, et surtout par le manque de programmeurs formés.[réf. nécessaire] Notons aussi le langage <a href="F_Sharp" title="F Sharp">F#</a> développé par <a href="Microsoft_Research" title="Microsoft Research">Microsoft Research</a> est disponible sous <a href="Licence_de_logiciel" title="Licence de logiciel">licence de logiciel</a> libre<a href="#cite_note-7">[7]</a> en 2010<a href="#cite_note-8">[8]</a>.

Quoique les palmarès de la <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a href="https://en.wikipedia.org/wiki/ICFP_Programming_Contest" class="extiw external" title="en:ICFP Programming Contest">compétition ICFP</a> démontrent le contraire[non neutre], les langages fonctionnels souffrent dans le premier quart du <abbr class="abbr" title="21ᵉ siècle">XXIe</abbr> siècle d'une réputation de lenteur aujourd'hui complètement injustifiée<a href="#cite_note-fallacy-9">[9]</a>[source insuffisante][non neutre] : certains compilateurs <a href="Scheme" title="Scheme">Scheme</a>, comme les compilateurs Stalin ou Bigloo, les compilateurs pour <a href="Common_Lisp" title="Common Lisp">Common Lisp</a>, les langages dans la lignée de <a href="ML_(langage)" title="ML (langage)">ML</a>, tels que <a href="OCaml" title="OCaml">OCaml</a>, <a href="Haskell" title="Haskell">Haskell</a> ou encore <a href="CDuce" title="CDuce">CDuce</a> produisent des exécutables dont les performances moyennes sont comparables, en termes de temps d'exécution et d'espace, à ceux produits par les compilateurs <a href="C_(langage)" title="C (langage)">C</a> ou <a href="C%2B%2B" title="C++">C++</a>.[source insuffisante]

Un code sans effet de bord étant beaucoup plus robuste et plus facile à maintenir, on le préférera à un programme dont la gestion de la mémoire et la prédiction du comportement seront difficiles à maîtriser, quitte à perdre un peu en efficacité[réf. nécessaire]. En outre, il faut aussi signaler les travaux de Chris Okasaki sur les structures de données purement fonctionnelles<a href="#cite_note-10">[10]</a> qui rivalisent avec les structures mutables en efficacité et les outrepassent largement quand il s'agit de la robustesse[réf. nécessaire].

En dehors des universités et de secteurs industriels spécifiques, <a href="Extensible_Stylesheet_Language_Transformations" title="Extensible Stylesheet Language Transformations">XSLT</a> peut être un vecteur de popularisation du paradigme fonctionnel. Dédié au traitement <a href="Extensible_Markup_Language" title="Extensible Markup Language">XML</a>, il permet à un programmeur de conserver ses langages <a href="Programmation_imp%C3%A9rative" title="Programmation impérative">impératifs</a> ou <a href="Programmation_orient%C3%A9e_objet" title="Programmation orientée objet">objets</a>, tout en découvrant une autre logique de programmation.

De même les langages <a href="Scala_(langage)" title="Scala (langage)">Scala</a> et OCaml, qui se veulent des langages fonctionnels, permettent au programmeur qui en aurait besoin de rester dans une logique de programmation impérative.

<div class="mw-heading mw-heading2"><h2 id="Notes_et_références">Notes et références</h2></div>

<li id="cite_note-monades-1">Il s'agit là d'un raccourci hâtif, mais le lecteur doit retenir que les langages fonctionnels n'ont pas a priori d'état. Cependant, grâce à la théorie des <a href="Monade_(informatique)" title="Monade (informatique)">monades</a>, on peut y adjoindre des états, mais alors il faut le faire de façon explicite et consciente ; c’est l'affaire de programmeurs experts, et cette technique sort du cadre de cet article.

</li>

<li id="cite_note-2"><a href="#cite_ref-2">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Paul Hudak, « <cite style="font-style:normal" lang="en">Conception, evolution, and application of functional programming languages</cite> », <a href="Association_for_Computing_Machinery" title="Association for Computing Machinery">ACM</a> Computing Surveys, <abbr class="abbr" title="volume">vol.</abbr> 21, <abbr class="abbr" title="numéro">no</abbr> 3,‎ <time class="nowrap" datetime="1989-09" data-sort-value="1989-09">septembre 1989</time>, <abbr class="abbr" title="pages">p.</abbr> 359-411 (<a rel="nofollow" class="external text" href="http://www.cs.berkeley.edu/~jcondit/pl-prelim/hudak89functional.pdf">lire en ligne</a>)<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=%27%27Conception%2C+evolution%2C+and+application+of+functional+programming+languages%27%27&rft.jtitle=ACM+Computing+Surveys&rft.issue=3&rft.aulast=Hudak&rft.aufirst=Paul&rft.date=1989-09&rft.volume=21&rft.pages=359-411&rft_id=http%3A%2F%2Fwww.cs.berkeley.edu%2F~jcondit%2Fpl-prelim%2Fhudak89functional.pdf&rfr_id=info%3Asid%2Ffr.wikipedia.org%3AProgrammation+fonctionnelle">

</li>

<li id="cite_note-3"><a href="#cite_ref-3">↑</a> auxquels il faut ajouter <a href="XSLT" class="mw-redirect" title="XSLT">XSLT</a> et Anubis.

</li>

<li id="cite_note-4"><a href="#cite_ref-4">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://reference.wolfram.com/language/guide/FunctionalProgramming.html"><cite style="font-style:normal;" lang="en">Functional Programming</cite></a> »

</li>

<li id="cite_note-5"><a href="#cite_ref-5">↑</a> « <a rel="nofollow" class="external text" href="https://web.archive.org/web/20071113175801/http://amath.colorado.edu/computing/mmm/funcproc.html"><cite style="font-style:normal;">Functional vs. Procedural Programming Language</cite></a> », sur web.archive.org, <time class="nowrap" datetime="2007-11-13" data-sort-value="2007-11-13">13 novembre 2007</time> (consulté le <time class="nowrap" datetime="2024-04-03" data-sort-value="2024-04-03">3 avril 2024</time>)

</li>

<li id="cite_note-6"><a href="#cite_ref-6">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Manuel M. T. Chakravarty, Gabriele Keller, « <cite style="font-style:normal" lang="en">The risks and benefits of teaching purely functional programming in first year.</cite> », J. Funct. Program, <abbr class="abbr" title="volume">vol.</abbr> 14(1),‎ <time>2004</time>, <abbr class="abbr" title="pages">p.</abbr> 113-123<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=The+risks+and+benefits+of+teaching+purely+functional+programming+in+first+year.&rft.jtitle=J.+Funct.+Program&rft.date=2004&rft.volume=14%281%29&rft.pages=113-123&rfr_id=info%3Asid%2Ffr.wikipedia.org%3AProgrammation+fonctionnelle">

</li>

<li id="cite_note-7"><a href="#cite_ref-7">↑</a> Plus précisément sous la <a href="Licence_Apache" title="Licence Apache">licence Apache</a>

</li>

<li id="cite_note-8"><a href="#cite_ref-8">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://blogs.msdn.com/b/dsyme/archive/2010/11/04/announcing-the-f-compiler-library-source-code-drop.aspx">Announcing the F# Compiler + Library Source Code Drop, par Don Syme le 4 Nov 2010</a>: « This source code is under the Apache 2.0 license and is published as part of the F# PowerPack codeplex project, which is now also under the Apache 2.0 license. The F# PowerPack now includes libraries, tools and the compiler/library source code drops. »

</li>

<li id="cite_note-fallacy-9"><a href="#cite_ref-fallacy_9-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://scienceblogs.com/goodmath/2006/11/02/the-c-is-efficient-language-fa/">The “C is Efficient” Language Fallacy</a> in ScienceBlogs.

</li>

<li id="cite_note-10"><a href="#cite_ref-10">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Chris Okasaki, « <cite style="font-style:normal" lang="en">Purely functional data structures</cite> », Cambridge University Press New York, NY, USA,‎ <time>1998</time> (<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> 0-521-63124-6)<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Purely+functional+data+structures&rft.jtitle=Cambridge+University+Press+New+York%2C+NY%2C+USA&rft.aulast=Okasaki&rft.aufirst=Chris&rft.date=1998&rft.isbn=0-521-63124-6&rfr_id=info%3Asid%2Ffr.wikipedia.org%3AProgrammation+fonctionnelle">

</li>

</ol></div>

</div>

<div class="mw-heading mw-heading2"><h2 id="Voir_aussi">Voir aussi</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Articles_connexes">Articles connexes</h3></div>

<ul><li><a href="Fonction_(math%C3%A9matiques)" title="Fonction (mathématiques)">Fonction (mathématiques)</a></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Bibliographie">Bibliographie</h3></div>

<ul><li>Julien Dehos, La programmation fonctionnelle - Introduction et applications en Haskell à l'usage de l'étudiant et du développeur, Ellipses, 2019</li></ul>

</div>

<ul id="bandeau-portail" class="bandeau-portail"><li> Portail de la programmation informatique </li> <li> Portail de l'informatique théorique </li> </ul></div><div><div class="zim-footer">

Cet article est issu de <a class="external text" title="Dernière modification le 2025-08-03" href="https://fr.wikipedia.org/wiki/?title=Programmation_fonctionnelle&oldid=227821053">Wikipédia</a>. Sauf mention contraire, le texte est disponible sous <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.fr">Creative Commons Attribution-Share Alike 4.0</a>. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.

</div>

</div></div>

</div>

</main>

</div>

</body></html>